`FilterPushdown::new_post_optimization()` was ANDing a fresh
`DynamicFilterPhysicalExpr` onto the probe-side scan's predicate on
every invocation. After N passes the probe-side data source carried
`DynamicFilter AND DynamicFilter AND ...` (N copies of the same empty
expression).

Root cause: `HashJoinExec::gather_filters_for_pushdown` always created a
new dynamic filter in the Post phase, regardless of whether the join
already had one from a prior pass. The previous-pass filter is retained
on the `HashJoinExec` itself (the `dynamic_filter` field is preserved
through `with_new_children` via the builder) and the same
`Arc<DynamicFilterPhysicalExpr>` is wired into the probe-side scan's
predicate, so a new one is redundant and stacks duplicates.

Fix: skip dynamic filter creation when `self.dynamic_filter.is_some()`.
The existing shared `Arc` keeps the probe-side scan correctly wired to
the build-side accumulator that will populate it.

Motivation: adaptive execution in datafusion-ballista AQE
(apache/datafusion-ballista#1359) re-runs the entire `PhysicalOptimizer`
chain after every completed stage. Unlike `OutputRequirements` (whose
duplicate wrappers are masked by `new_remove_mode` later in the chain),
this duplication survives to the executed plan and degrades scan
performance with redundant filter evaluation.

Adds `post_phase_is_idempotent_on_hash_join` to
`datafusion/core/tests/physical_optimizer/filter_pushdown.rs`: builds a
hash join over two parquet scans, invokes the rule twice, asserts the
plan strings match. Fails before this fix (two `AND DynamicFilter`
clauses on the probe side); passes after.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>